In computing, an enterprise service bus serves as the integration platform within service-oriented architectures. The enterprise service bus (ESB) refers to an abstraction layer on top of an implementation of an enterprise messaging system that attempts to remove the coupling between the messaging service called and the transport medium. The ESB may be implemented as software or as a hardware device. The ESB is responsible for, along with many other functions, enforcement of policies, routing of service requests, and performing content and/or transport protocol transformation. There are numerous technical and business issues which affect the choice of topology for the deployment of ESBs.
It is often desirable to have multiple ESB deployments federate with one another to provide a distributed integration platform that promotes the reuse of services within the enterprise. The term federation refers to a group of two or more ESB deployments that share at least some routing state. The goal of federation is to provide a logically centralized (at an appropriate scope) integration infrastructure across different geographic and business boundaries. Assuming that one or more services have already been manually deployed and hosted through an ESB, there are three known solutions to federate ESB deployments together to support reuse of services throughout an enterprise: manual configuration, utilizing a broker ESB, or deploying a centralized service registry.
One way of federating ESBs is by manually configuring functionality within an ESB that serves as a “proxy” to other ESBs in the federation. For each service that is managed by a remote ESB, a mediation on the ESB must be defined that selects appropriate requests to be forwarded to the remote ESB, performs necessary content/protocol transformations, and then forwards the request onto the remote ESB. Matching mediations must exist on remote ESBs in order to support bidirectional communication in this case. Since this configuration must be done manually by a systems administrator at each ESB, the configuration of such a solution is tedious and prone to error (for S services and N ESBs, there are possibly SN proxies to be configured). There is also no mechanism to change the properties of this mediation based on changes in network or service availability. Manual configuration allows basic federation of multiple ESBs; however, this is an inflexible and impractical solution for large scale enterprises.
Rather than statically defining the routing mediations at each ESB, a separate ESB called a “broker” ESB can be deployed whose sole function is to implement the requisite mediations to support the federation. This helps to consolidate the many different mediations that might exist in the manually configured solution described above into a single ESB. However, this consolidation is still dependent on a systems administrator to manually define the mediations required for each service (in this case, the number of proxies to be configured is minimized to S). Since there is no mechanism to update the mediation metadata based on dynamic service availability, the broker ESB solution is inflexible. The broker ESB then becomes the architectural bottleneck, which introduces issues with scalability and fault tolerance.
The final known approach is to deploy a centralized registry for the entire enterprise. When ESBs need to route service requests to other ESBs, the ESBs consult a central registry at runtime to make a forwarding decision based on the current location of a service instance, thus addressing the manual configuration concerns raised by the previous solutions (as with the broker ESB, the number of entries in the centralized registry is equal to the number of services). However, centralizing all service metadata and status into a single registry forces the registry to be the architectural bottleneck in such a federated system, causing concerns with system performance, scalability, and fault tolerance. The centralized registry is ideal from the standpoint of the consolidation of service information, but is infeasible in many realistic business scenarios due to B2B interactions, disparate geographical locations, and limitations imposed by business structures. Today, manual configuration of the centralized registry is required to insert/update/delete service metadata, which limits the flexibility of this solution.
In summary, the existing approaches to federating ESBs require tedious manual configuration, which is prone to errors and inflexible to dynamic IT environments. The broker ESB and centralized registry approaches require the consolidation of service metadata into a centralized location, which causes concerns with scalability and reliability of the integration infrastructure.